1. Field of the Invention
This invention relates to data communications and data delivery over communication media between a host computer and a device, such as in host computer-based measurement systems.
2. Description of the Related Art
In many applications it is necessary or desirable for a host computer system to communicate data with an external device. Various transmission media and protocols exist for enabling communication between a host computer system and an external device. Examples of these types of external transmission media include the Universal Serial Bus (USB), IEEE 1394, and other serial or parallel buses which enable communication, e.g., packet-based communication. Typically, the host computer system includes communication logic for interfacing with the external communication line. For example, in a computer system which includes USB communication capabilities, the computer system typically includes a USB host controller for communication with the USB. The computer system also typically includes various layers of driver software which allow an application to interface with and use the external communication media for communicating with the external device.
In some systems serial interface hardware may be used to facilitate communication between the host computer and the external device. As one example, USB systems may include a remote USB hub for coupling to various USB devices. As another example, the host computer may communicate over the USB with a serial interface, wherein the serial interface in turn communicates with the external device according to a different interface or bus standard. For example, the host computer may communicate over the USB with a serial interface, which in turn may communicate with a GPIB device over a General Purpose Interface Bus (GPIB).
One problem that often arises with host computer driver software which is used to interface to an external communication medium is that the driver software requires numerous context switches between user mode and kernel mode. As is well known in the art, a user mode/kernel mode transition requires a context switch by the CPU, which generally requires a large amount of CPU resources or cycles. Therefore, it would be desirable to provide a driver implementation which is operable to communicate with an external communication medium that minimizes user mode/kernel mode transitions.
Additionally, communication of commands to the device may involve significant overhead. For example, in a typical USB system the transfer of a single low level command may take as long as 3 ms. If a high level command involves 20 low level commands transferred over the bus, an overhead of 60 ms may accrue. Therefore, it would be desirable to provide a driver implementation which minimizes transfer overhead.
FIG. 1 illustrates the software architecture of prior art systems referred to as the GPIB-USB and the GPIB-1284CT from National Instruments Corporation. This software architecture operates in a system that includes a serial bus interface 110A (or parallel port in the case of the 1284CT) for communicating with an external device. The software architecture of FIG. 1 presumes a host computer 108A communicating with the external serial bus interface device 110A. The software architecture includes application software 602A and a software driver. As shown, the software driver is implemented in multiple software layers for modularity. The driver software layers include driver entry layer 604A, driver manager/class layers 606A, driver algorithms layer 608A and hardware access routines layer 610A. The block labeled xe2x80x9cRegister Accesses 612Axe2x80x9d represents the hardware registers on the serial bus interface 110A, i.e., the accesses that are performed on the serial bus interface 110A by the hardware access routines layer 610A.
As FIG. 1 shows, host 108A stores and executes application software 602A, driver entry layer 604A, driver manager/class layer 606A, driver algorithms layer 608A, and driver hardware access routines 610A. The driver hardware access routines 610A perform individual low level register accesses across the serial bus to the serial interface 110A, as represented by driver register accesses 612A. In this approach, the entire driver comprising blocks, 604, 606, 608 and 610 executes on the host computer 108A, and the host system communicates with the serial bus interface 110A using low level register accesses, i.e., register reads and writes.
In the prior art GPIB-USB system, the application software 602 and the driver software operate as follows. Application software 602A may communicate with a driver entry layer 604A, such as National Instruments NM-488.2 Entry layer, which provides an entry point for application communication with the device. The entry layer presents an Application Programming Interface (API) to the application for interacting with the interface driver and serializing calls to the driver. The entry layer 604A in turn communicates with manager/class driver software 606A, such as National Instruments NI-488.2 Manager/Class layers, which determines to which hardware to send the communications, and which is responsible for reading configuration information for a board/device from persistent storage and passing these settings down the driver stack. The Class layer has GPIB board and device software objects with methods that correspond to most of the user callable NI-488.2 functions. These objects are initialized with the board/device settings passed down from the Manager layer.
The manager/class driver software communicates with a driver algorithm layer 608A, such as National Instruments NI-488.2 Algorithms layer, which provides higher level control structures, such as looping, for controlling the device. The algorithms layer 608A communicates with hardware access routines layer 610A, which in turn, performs individual low level register accesses 612A across the serial bus to the interface 110A. As can be seen, the entire driver functionality is located on the host computer 108A. Thus, the interface device 110A is a xe2x80x9cdumbxe2x80x9d device, and hence a less expensive device. The host computer 108A was required to send each individual register access command over the bus one at a time and make sure the command completed successfully before sending the next one. This approach to the driver implementation results in low performance, in that each individual register access by the driver software must be transmitted over the bus one at a time, and thus the overhead associated with the transfers accumulates rapidly.
In this prior art GPIB-USB system, the driver software and/or the USB device included various novel features to improve the speed and efficiency of transfers. For example, the GPIB-USB system implemented read pre-fetching/caching and write posting techniques to improve performance. For more information on these techniques, please see U.S. Pat. Nos. 5,987,530 and 6,073,025.
FIG. 2 illustrates an alternate software architecture according to the prior art. The software architecture of the system of FIG. 2 attempts to address the above problems of bus transaction overhead by locating and executing a large portion of the driver (essentially the entire driver) in the remote interface 110B. FIG. 2 illustrates the software architecture of a prior art system, referred to as the GPIB-ENET product from National Instruments. The GPIB-ENET product is an Ethernet to GPIB converter interface for converting between Ethernet packets and GPIB packets. In the software architecture of FIG. 2, substantially all of the GPIB driver executes in the remote interface 110B.
As FIG. 2 shows, host 108A stores and executes application software 602A, driver entry layer 604A, and driver manager/class layer 606A. The remote bus interface 110B stores and executes driver algorithms layer 608A and driver hardware access routines 610A, which execute to perform driver register accesses 612A. In this approach the host system 108A communicates with the bus interface 110B using high-level frames.
Application software 602A may communicate with the driver entry layer 604A, and the driver entry layer 604A in turn communicates with the manager/class driver software 606A.
The manager/class driver software 606A communicates (over the Ethernet bus) with the driver algorithm layer 608A. As noted above, the driver algorithm layer 608A provides higher level control structures, such as looping, for controlling the device. The algorithms layer 608A executing on the remote bus interface communicates with hardware access routines layer 610A, which in turn performs register accesses 612A on the interface 110B.
As can be seen, the bulk of the driver functionality is located on the remote interface, which requires that the remote interface 110B have sufficient memory and processing power to execute the driver software. However, providing these resources on the bus interface 110B involves significant cost to the interface 110B. Therefore, the driver software architecture of FIG. 2 enables high level commands to be sent over the Ethernet bus to the interface 110B, thus reducing bus overhead. However, due to the large processor and memory requirements, primarily the requirements related to executing the algorithms layer 608A, the interface 110B is relatively expensive.
Therefore, an improved method and system for communication between a host computer and an external device is desired.
The present invention comprises various embodiments of a system and method for communicating with a device over an external transmission medium. In one embodiment, the system may comprise a host computer system which couples through a serial bus to an external serial bus interface. The serial bus interface may in turn couple through an interface bus to the device.
The host computer system may include a host CPU and a host memory, wherein the host memory may store and execute a user application, a serial bus interface driver, and a first portion of an interface driver. The host computer may further include a serial bus host controller. The serial bus host controller of the host computer may couple to the serial bus. The serial bus interface couples to the serial bus and may include an interface connector adapted to couple through the interface bus to the device. The serial bus interface may be operable to execute a second portion of the interface driver, and the serial bus interface may be operable to communicate signals over the interface bus to the device in response to the execution of the second portion of the interface driver.
In one embodiment the host computer system stores and executes one or more layers of the interface driver software, including the algorithm layer of the interface driver, and the serial bus interface executes hardware access routines for accessing the hardware registers on the serial bus interface. Thus, in one embodiment the second portion of the interface driver may include primarily only hardware access routines (register access routines), may include limited hardware configuration information, and may not include higher level interface algorithms. Thus, the serial bus interface may include a relatively inexpensive processor and a relatively small amount of memory, and accordingly the serial bus interface may be relatively inexpensive. In addition, the first driver portion executing on the host computer may operate to package up related low level commands into a single frame or packet and provide this single frame or packet to the serial bus interface in a single transfer. The first driver portion executing on the host computer may further operate to package up related low level commands into a single frame using only a single user mode/kernel mode context switch. Thus, this embodiment may operate to provide a relatively inexpensive serial bus interface while providing the advantages of reduced bus transactions and reduced user mode/kernel mode context switches.
In one embodiment, the method operates as follows. First, the user application may generate an API function call to the interface driver. The first portion of the interface driver executing on the host computer receives the API function call, generates a plurality of low level interface commands based on the API function call, and generates a frame encapsulating the plurality of low level interface commands. The first portion of the interface driver may generate the frame encapsulating the plurality of interface commands with a reduced number of user mode/kernel mode transitions, e.g., only one user mode/kernel mode transition. The serial bus host controller may then send the frame over the serial bus in a single bus transfer to the serial bus interface. The serial bus interface may then execute the second portion of the interface driver to execute the plurality of interface commands comprised in the frame. In one embodiment, in executing the second portion of the interface driver, the serial bus interface executes hardware access routines for unpacking the frame to retrieve the plurality of interface commands and executing the commands to read/write registers on the serial bus interface. The serial bus interface may then transmit signals or commands over the interface bus to the device in response to executing the plurality of interface commands.
In one embodiment the serial bus may be a Universal Serial Bus (USB), the serial bus host controller may be a USB host controller, and the serial bus interface driver may be a USB driver. In one embodiment, the interface bus may be a General Purpose Interface Bus (GPIB) for connecting to a GPIB device, and the serial bus interface may perform serial bus to GPIB bus conversions. Hence the first portion of the interface driver executing on the host and the second portion of the interface driver executing on the serial bus interface may comprise a first portion of a GPIB driver and a second portion of a GPIB driver, respectively.
In an alternate embodiment, the system may comprise a host computer system which couples through a bus, such as a serial bus, to a device, wherein the host computer system executes a first portion of a device driver for communicating with the device and the device executes a second portion of the device driver. In this embodiment, the host computer system executes one or more layers of the device driver, including the algorithms layer of the device driver, and the device executes hardware access routines for accessing the hardware registers on the device. Thus, as with the embodiment described above, the device may include a relatively inexpensive processor and a relatively small amount of memory, and accordingly the device may be relatively inexpensive. In addition, the first driver portion executing on the host computer may operate to package up related low level commands into a single frame or packet and provide this single frame or packet to the device in a single transfer. The first driver portion executing on the host computer may further operate to package up related low level commands into a single frame using only a single user mode/kernel mode context switch. Thus, this embodiment may operate to provide a relatively inexpensive device while providing the advantages of reduced bus transactions and reduced user mode/kernel mode context switches.